The requirements phase is the most critical phase of the software development life cycle (SDLC). The quality of the requirements gathered during requirement phase affects the overall quality of the subsequent phases and hence, the software product. In the current business environment, about 50% of the software production or post release defects could be traced back to incorrect requirements. Fixing up these defects takes a significant amount of time and money and leads to cost and schedule overruns. A cost analysis shows that the cost associated with fixing the defects increases significantly with the defect discovery stage in the SDLC. Thus, when a defect is leaked into production, the cost of fixing that defect and testing the solution is the costliest. For example, if a defect that could have been detected in testing phase or in development phase is detected post release, then it would cost about 20-400 times more to fix than if the defect had been detected in the development phase or the testing phase itself. Further, only about 34% of projects are delivered on time and budget, and poor requirement quality is one of the major contributors to this problem.
Despite the availability of vast literature and best practices on requirements gathering, requirements still fail to meet quality benchmarks due to a variety of reasons ranging from miscommunication, stakeholder availability, manual validation processes, and so forth. Poorly captured requirements are prone to a number of quality problems or violation types such as ambiguity, atomicity, incompleteness, duplicity, non-specificity, un-verifiability, contradictory, and so forth. These quality violations in the captured requirements may lead to subsequent requirement volatility which leads to rework, cost overruns and schedule deviation, thereby significantly impacting business and project outcomes. For example, poorly captured requirements may be used as a reference for the software development leading to poor design, poor code, and on many occasions incorrect features and defects.
Additionally, projects also fail to differentiate between functional and non-functional requirements and treat them the same way for use case modeling which further impacts the output quality. Poorly documented functional requirements are far more critical as they form the core of the system and should be corrected as early as possible. Further, in Agile software development methodologies involving quick sprints, multiple iterations, and unclear goals, the manual methods of requirements validation is limiting because of being a time consuming process resulting in a negative impact on the overall sprint velocity. It is evident that identifying defects at the earlier stages of SDLC has significant effort and cost savings. However, due to the constraints related to requirements validation, the defects usually pass on to the testing phase and in some cases the unidentified defects creep into the further stages and are also found after deployment. Such defects are not only costly to fix but also difficult to fix due to the complex systems and the impact on business.
In short, requirements gathering and validation is a key phase but such quality violations continue to percolate frequently because of time and technology constraints. While such violations adversely impact the development unit in terms of cost and schedule, it also has a tremendous impact on the business in terms of time to market, reputation, and the bottom-line.